home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ietf / mhsds / mhsds-minutes-92mar.txt < prev    next >
Text File  |  1993-02-17  |  7KB  |  136 lines
  1. This is only a rough draft - Megan 04/13/92
  2.  
  3. Minutes of the 1st meeting of the IETF MHS-DS Working Group
  4. San Diego, California
  5. March 17, 1992
  6. Reported by Kevin Jordan
  7.  
  8. The first meeting of the MHS-DS Working Group took place on March 17
  9. in San Diego.  The duration of the meeting was two hours, from 10:00
  10. until 12:00.  Despite the shortness of time, very good progress was
  11. made.
  12.  
  13. The meeting was co-chaired by:
  14.  
  15.      Harald Tveit Alvestrand of Delab Sintef, Norway
  16.      Kevin Jordan of Control Data Corporation, Arden Hills, Minnesota, USA
  17.  
  18. After brief introductions and a review of the working group charter,
  19. Steve Hardcastle-Kille provided an overview of his paper entitled
  20.  
  21.     "PP Use of Directory"
  22.  
  23. This paper defines a comprehensive approach for using X.500 Directory Services
  24. to support X.400 routing, RFC1148 address mapping, distribution list expansion,
  25. and various other purposes suited to electronic mail.  The paper establishes
  26. the basis for further work by the MHS-DS Working Group.
  27.  
  28. The working group decided that the following seven draft RFC's will be
  29. derived from "PP Use of Directory":
  30.  
  31.      1. An RFC which describes how to represent tables in the directory
  32.         and which also defines the concept of X.400 routing trees.
  33.  
  34.      2. An RFC which defines the mechanism for mapping X.400 O/R addresses
  35.         onto X.500 distinguished names.  This RFC will define the basic
  36.         mapping rules, and it will also describe how knowledge information
  37.         and cross references can be used to avoid unnecessary chaining and
  38.         referrals through DSA's managed by ADMD service providers.
  39.  
  40.      3. An RFC which defines the mechanism for using X.500 Directory Services
  41.         to support X.400 routing.  This RFC will draw heavily from the
  42.         concepts defined in the first two RFC's.
  43.  
  44.      4. An RFC which defines the mechanism for using X.500 Directory Services
  45.         to support mapping between RFC822 addresses and X.400 addresses, in
  46.         compliance with RFC1148bis.  This RFC will also draw heavily from the
  47.         concepts defined in the first two RFC's.
  48.  
  49.      5. An RFC which defines mechanisms for using X.500 Directory Services
  50.         to support practical implementations of distribution list expansion
  51.         and management.
  52.  
  53.      6. An RFC which defines mechanisms for using X.500 Directory Services to
  54.         support RFC822 mail routing and distribution.
  55.  
  56.      7. An RFC which defines a simple profile of the other RFC's, especially
  57.         RFC's 1 through 4.  This RFC could be used as a guide to producing
  58.         minimal implementations of the first six RFC's above.
  59.  
  60. We agreed that these RFC's should be released initially as Experimental
  61. Drafts.  As working implementations become available and practical experience
  62. establishes proof of concept, the RFC's will be evolved into Internet
  63. Standards.  The Working Group openly expressed optimism that working
  64. implementations would be available by the end of this year.  In fact, a
  65. PP-based prototype is already underway.
  66.  
  67. The first four RFC's have top priority.  They will be created and distributed
  68. before the last three.  Our goal is to bless the final drafts of the first
  69. four documents at the next general IETF meeting in Boston this summer.
  70.  
  71. It was generally agreed that well performing implementations of these
  72. RFC's will need to implement mechanisms for caching information obtained
  73. from the directory.  This will be necessary in order to minimize the
  74. number of directory operations requested during normal operations, thereby
  75. optimizing response time in critical functions such as route discovery.
  76. A recommendation was made that at least one of the RFC's should provide
  77. guidelines for the implementation of caching.  In particular, guidelines
  78. should be provided for recommended time-to-live values of cache entries.
  79.  
  80. Harald reminded/informed the working group of related work occurring within
  81. ISO.  Specifically, R.H. Willmott has written a paper concerned with
  82. using X.500 Directory Services in support of X.400.  This paper is being
  83. circulated within the ISO standardization community.  Harald brought a copy
  84. of the paper to San Diego and provided copies to the MHS-DS membership.
  85. We agreed to review this paper and evaluate its relevance to our work plan.
  86.  
  87. Before the meeting was closed, Steve Hardcastle-Kille summarized some new
  88. features which will be added to the RFC's in response to comments he has
  89. received recently.  These features include:
  90.  
  91.      1. Improvement in the mechanism for defining and managing MTA
  92.         passwords in the directory.  Specifically, a mechanism will be
  93.         defined for using the normal X.500 compare operation to compare
  94.         MTA passwords.  It is likely that this will enhance the security
  95.         of MTA passwords stored in the directory.
  96.  
  97.      2. Added support for explicitly defining a UA which always causes
  98.         nondelivery reports to be generated.  It is not clear how useful
  99.         this feature truly is, but it does provide a mechanism for catching
  100.         undeliverable X.400 addresses as early as possible.
  101.  
  102.      3. Added a hook for discovering MTA's which are common to a community
  103.         of recipients.  This feature allows mutually remote MTA's to optimize
  104.         their usage of network resources by detecting that a large group
  105.         of recipients can be reached by relaying mail through a common
  106.         MTA which will perform a distribution function.  For example, an
  107.         MTA in the US can use this feature to send a single copy of a
  108.         message to a WEP in France, and the French WEP will distribute
  109.         the message to a group of MTA's within France.  This optimizes
  110.         utilization of the network link between the US and France.
  111.  
  112. Action items:
  113.  
  114.     1. Kevin Jordan will update the MHS-DS charter such that it specifies
  115.        the RFC's we intend to produce and the time-frame in which we intend
  116.        to produce them.
  117.  
  118.     2. Steve Hardcastle-Kille will generate the first four draft RFC's
  119.        from his "PP Use of Directory" paper and make them available to the
  120.        working group for review and comment.  He will accomplish this prior
  121.        to the upcoming JENC-3 conference in May.
  122.  
  123.     3. Erik Huizer will provide Steve with an OID to be used for
  124.        identifying the new draft RFC's.
  125.  
  126. Future meetings:
  127.  
  128.    The next meeting of the MHS-DS Working Group will take place at the
  129.    upcoming JENC-3 (3rd annual Joint European Networking Conference) in
  130.    Innsbruck, Austria.  The meeting will probably take place on Friday,
  131.    May 15.
  132.  
  133.    The third meeting of the MHS-DS Working Group will take place at the
  134.    next general IETF meeting in Boston, Massachusetts, in July.
  135.  
  136.